The present invention relates generally to persistent (or “sticky”) server connections, and more specifically, persistent connections based on the natural class of a subnet.
Applications that communicate over the Internet typically communicate with each other over a transport layer Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) connection. TCP/IP is an industry standard suite of protocols designed for large internetworks spanning wide area network (WAN) links. TCP/IP was developed in 1969 by the U.S. Department of Defense Advanced Research Projects Agency (DARPA), the result of a resource-sharing experiment called ARPANET (Advanced Research Projects Agency Network). The purpose of TCP/IP was to provide high speed communication network links. DARPA and other government organizations understood the potential of packet-switched technology and were just beginning to discover that virtually all companies with networks needed to support communication among dissimilar computer systems. With the goal of heterogeneous connectivity in mind, DARPA funded research by Stanford University and Bolt, Beranek, and Newman to create a series of communication protocols. The result of that development effort was the Internet protocol suite, of which the Transmission Control Protocol (TCP) and the Internet Protocol (IP) are the two best-known members.
TCP is a connection-orientated transport layer protocol that sends data as an unstructured stream of bytes. By using sequence numbers and acknowledgment messages, TCP can provide a sending node with delivery information about packets transmitted to a destination node. Where data has been lost in transit from source to destination, TCP can retransmit the data until either a timeout condition is reached or until successful delivery has been achieved. TCP can also recognize duplicate messages and will discard them appropriately. If the sending computer is transmitting too fast for the receiving computer, TCP can employ flow control mechanisms to slow data transfer. TCP can also communicate delivery information to the upper-layer protocols and applications it supports. As a result of these capabilities, TCP is a connection oriented protocol.
IP is the primary network layer protocol in the Internet suite. In addition to internetwork routing, IP provides error reporting and fragmentation and reassembly of information units called datagrams for transmission over networks with different maximum data unit sizes. In the TCP/IP protocol, in order to properly route packets, it is necessary to use the source IP address and port number and the destination IP address and port number found in the packet header.
For many business enterprises, it has become important to reach customers, vendors, and employees through the Internet. Web-based communication is different from mainframe and client-server arenas. One difference is that HTTP (HyperText Transfer Protocol), an underlying protocol of Web communication, is both connectionless and stateless. This causes a problem for dynamic interactions with the user where a Web system needs to be able to keep track of the user's state during a session involving multiple Web interactions (e.g., Web page requests). Without a way to manage state between Web transactions, the system will forget information about the user and the context of the session. This can be further complicated by the fact that in many large Web systems the user does not interact with the same Web server from transaction to transaction.
Moreover, in Web applications, it is often necessary to provide a persistent or “sticky” connection between a browser (the user) and the Web or database server to which it is connected. A sticky connection allows a server load balancer to direct each client connection in a session to the same server so that all requests from a given client are redirected to the same server and the client remains attached to a single server for the duration of the transaction between the client and the server. Examples of applications that require a sticky connection include shopping baskets, financial transactions, and some forms of interactive games. Because HTTP does not carry any state information for these applications, it is important for the browser to be mapped to the same server for each HTTP request until a user's transaction is complete.
The sticky connection is often controlled by a configurable timer. If the timer is configured on a virtual server, new connections from a client are sent to the same real server that handled the previous client connection, provided that the amount of time between the end of a previous connection from the client and the start of a new connection is within the timer duration. If a session is timed out, the client may be connected to a different real server, thus losing state information.
Current implementations of sticky use the client IP address/TCP port, SSL session ID, or a user's cookies. As described below, each of these methods has drawbacks.
A TCP connection is initialized through a three-way handshake which is used to synchronize the sequence number and acknowledgement numbers of both sides of the connection and exchange segment sizes. The client first sends a TCP segment to the server with an initial sequence number for the connection and maximum segment size. The server sends back a TCP segment containing its chosen initial sequence number, an acknowledgement of the client's sequence number, and a maximum segment size. The client then sends a TCP segment to the server containing an acknowledgement of the server's sequence number. If an acknowledgement is not received within a specified period of time a browser may time out the session.
SSL (secure socket layer) is encryption technology used to provide secure transactions on the Web, such as the transmission of credit card numbers for e-commerce. The SSL protocol uses a combination of public key and symmetric key encryption. An SSL session also begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client using public key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Web sites that use mixed SSL/non-SSL connections create problems for sticky connections. An example of a mixed SSL/non-SSL connection is an online vendor who provides a shopping cart for use in collecting items for purchase while browsing. Since the contents of the shopping cart are not considered confidential, most administrators deploy this area of the site in non-SSL pages. However, at checkout time when confidential information such as the user's credit card number is entered, the vendor switches to a secure SSL connection. Since the SSL session ID is effective only when the server is running SSL, the client may be switched to a different server during the transaction.
The cookie sticky keeps clients directed to the same physical or real server using standard HTTP cookie technology. Cookies are strings passed from servers to browsers using HTTP. After a client has received a cookie as the result of a “set cookie” HTTP command, any server can poll that cookie, providing it knows the structure, with a “get cookie” command. This allows the querying server to positively identify the client as the one that received the cookie earlier. In a server load balancer implementation, this technology may be used to route users back to the same real server based on the cookie the client shows the server load balancer. The cookie sticky typically does not work with SSL since the cookies are encrypted. Furthermore, the cookie can also time out, thus resulting in a new connection being made with possibly a different server.
Sticky may also be implemented using IP addresses. For example, the IP address of a user and the server that the user was connected to initially may be recorded. When a new request comes in from that same user the traffic is directed to the original server. The initial connection may be allocated to a specific server based on the type of application being requested or based on load balancing criteria. There are situations, however, where a client IP address will change, thus, using the IP address to provide a persistent connection will not work. For example, many firewalls translate the network address into one or more IP addresses managed by the firewall. In this way, the firewall can direct traffic to the Internet without actually exposing the IP address used internally by its protected network. The return address is the firewall and the firewall translates the address back to the user's address, and passes the packet along to the protected network. By also translating the port number, the firewall can use the same IP address among multiple users. This allows a network located behind a firewall to make thousands of connections to the Internet with only one IP address. However, with a large network, the firewall may need several IP addresses to distribute the traffic. Also, in the case where there is more than one firewall handling the network traffic, each firewall or an array of firewalls may translate a user's IP address into a different address for each TCP session. Thus, source persistence will not work in situations where the user's IP address changes, such as when the user resides behind a firewall or array of firewalls that use multiple IP addresses.
There is, therefore, a need for a method and system for implementing sticky connections despite the presence of a firewall or other network device that may modify a client IP address.